[Previous] [Next] [Index] [Thread]

Re: N$ SSL vs M$ PCT

> From: Adam Shostack  <adam@bwh.harvard.edu>
> To: Bennet Yee
> Cc:  <www-security@ns2.rutgers.edu>
> Subject: Re: N$ SSL vs M$ PCT
> Date: Tuesday, October 10, 1995 12:36PM
>
> 	The failure of a protocol [specification] to specify
> important facts known to
> its designers is a specifications failure.  The lack of communication
> you refer to needs to be addressed in the documents that implementors
> are most likely to read, ie, the specifications. As Ross Anderson
> points out in his 'Why Cryptosystems Fail' paper, the assumption by
> cryptographers that the programmers will know how to write security
> code does not hold up in the real world.
>
> 	Until and unless there is a body of knowledge out there in the
> general programing community, it behooves the designers of secure
> protocols to specify (possibly by reference) as much as possible.

Adam, I disagree with you.  The protocol specification describes the
protocol messages.  It is by no means a design document.  Nor is it
an implementer's guide.  Nor a journal submission.  When we wrote the
protocol specification, we also did not specify the API to be used
with the protocol, even though the API design -- as well as the user
interface of applications like Web browsers -- could have a very real
impact on the actual security of the resultant system.

We don't admonish programmers against overflowing their buffers nor
do we warn them against storing the users' private keys unencrypted
on the users' disk.  There are lots of cryptographic/security common
sense assumptions that we leave out.  We -do- tell the programmers to
use a cryptographically secure pseudo-random number generator.  That
is a fundamental assumption upon which the security of the protocol
is based, and it is something that programmers needs to know in order
to implement a server or a client.  Experience has shown us that it
is a little tricky and that programmers often get it wrong
(Netscape's browser, of course, and it was also a problem in
Kerberos).  We don't, however, tell them which cryptographically
secure random number generator to use, because that is a design
choice that is independent of the protocol messages.

The PCT protocol specification does not -- and cannot -- completely
describe all the security issues involved in a full, real
implementation.  Nor do we discuss the security characteristics of
the various encryption, hash, and signature functions that might be
negotiated.

When somebody sets forth to write an introduction to programming
book, she or he does not also write about issues in the language or
compiler design.  The dragon book does not address the semantics of
ML, the daemon book does not talk about the design and use of the C
language (versus C++, say) for systems implementation, and Hennesey
and Patterson does not talk about quantum device physics in any
detail.  While our PCT protocol specification is not a textbook, its
goal is similarly limited: we wanted to let people know the details
of the protocol quickly.  We did not include all of the analysis that
went into its design, nor did we intend it to be a training manual
for programmers who wish to learn to implement security code.

All of -that- are part of different documents.

Ross is right in that most programmers do not, in general, know how
to implement security code.  That does not, however, mean that a
training manual should be included as part of every protocol
specification.  Rather, I would argue that universities need to teach
(mini-)courses or that somebody needs to write a textbook that would
be a standard reference once and for all.

To get back to particulars, the case of key (mis-)reuse is an issue
that should probably be addressed at the Certificate Authority policy
level and placed in a systems-implementer's guide.  Reusing keys
should be covered by (cryptographic) common sense in the first place;
in any case, the likelihood that a programmer would decide to grab
the users' PGP or PEM keys is rather small.

-bsy
Follow-Ups: